Summary

fetchRepoIssues and searchIssues abandon pagination on the first non-OK page and return the pages they
already collected, with a warning (packages/discovery-index/src/github-client.ts:189-203):

    for (let page = 0; url !== null && page < this.maxPages; page += 1) {
      const response: Response = await this.fetchWithRetry(url);
      if (!response.ok) {
        warnings.push(`GitHub returned ${response.status} for ${repoFullName} issues`);
        return { issues, warnings };
      }
      const payload: unknown = await response.json().catch(() => null);
      if (!Array.isArray(payload)) {
        warnings.push(`GitHub returned a non-array issues payload for ${repoFullName}`);
        return { issues, warnings };
      }

searchIssues (packages/discovery-index/src/github-client.ts:214-231) has the identical shape. The caller
logs the warning and otherwise ignores it (packages/discovery-index/src/discovery-query.ts:176-178):

    const { issues, warnings } = await deps.github.fetchRepoIssues(repoFullName);
    surfaceGithubWarnings(repoFullName, warnings);
    for (const issue of issues) addCandidate(repoFullName, issue, verdict);

Two things then compound it:

1. runDiscoveryQuery caches whatever computeCandidates returned, for the full TTL
   (packages/discovery-index/src/discovery-query.ts:213-216):

     const allCandidates = await deps.resultCache.getOrCompute(scopeKey, deps.cacheTtlMs, () => {
       missed = true;
       return computeCandidates(query, deps);
     });

   A page-2 500 during one cold miss therefore pins a truncated candidate set for DEFAULT_CACHE_TTL_MS
   (300 s, packages/discovery-index/src/discovery-query.ts:40) for every caller sharing that scope. The
   whole point of the service is that many miners share one cached scope, so one transient GitHub failure is
   amplified across the fleet rather than isolated to the request that hit it.

2. The response then asserts completeness. runDiscoveryQuery emits
   nextCursor: nextOffset < allCandidates.length ? encodeCursor(nextOffset) : null
   (packages/discovery-index/src/discovery-query.ts:218-221), so a client walking the cursor reaches
   nextCursor: null and correctly concludes it has seen the whole set — which it has not. Nothing on the
   wire distinguishes "this scope really has 40 candidates" from "GitHub 500'd on page 2 and we have 40 of
   200". The only signal is a console.error warn line inside the server process.

This is the same class of gap the main app already closed for its own truncated GitHub reads: fetchRepoTree's
consumer treats a truncated tree as inconclusive and returns null rather than a short list
(src/github/migration-tree.ts:41-44), and fetchPullRequestFiles pushes an explicit truncation warning into
the review's own warnings so the PR is held rather than silently evaluated on a partial file set
(src/github/backfill.ts:2469-2476).

Deliverables

• computeCandidates returns both the candidate list and a completeness flag (or equivalent) derived from
  the warnings already collected at packages/discovery-index/src/discovery-query.ts:176-178, :183-185,
  :190-192.
• runDiscoveryQuery skips the resultCache write when the pass was incomplete. Exact expectation: with a
  GitHubClientLike stub whose fetchRepoIssues returns { issues: [oneIssue], warnings: ["GitHub returned 500 for owner/repo issues"] },
  two successive runDiscoveryQuery calls for the same query BOTH invoke fetchRepoIssues (i.e. the
  second call is a cache miss), and both responses carry the one candidate.
• A test in test/unit/discovery-index/discovery-query.test.ts asserting the unchanged happy path: a stub
  returning { issues: [...], warnings: [] } is called exactly once across two successive
  runDiscoveryQuery calls for the same query, and the second response is identical to the first.
• A test in test/unit/discovery-index/discovery-query.test.ts covering the searchIssues warning path
  (an orgs-scoped query) as well as the fetchRepoIssues path — both feed the same completeness flag and
  a partial fix could cover only one.
• A regression test at test/unit/discovery-index/discovery-query.test.ts named for this bug (e.g.
  "REGRESSION: a GitHub-failure-truncated candidate set is not cached for the TTL").

All Deliverables above are required in a single PR. A PR that satisfies only some of them — for example one
that threads the flag through computeCandidates but still calls resultCache.getOrCompute, so the truncated
set is written before the flag is ever consulted — does not resolve this issue.

Test plan

This repo enforces 99%+ Codecov patch coverage, branch-counted. vitest.config.ts's coverage.include
covers src/**/*.ts and packages/loopover-engine/src/**/*.ts — packages/discovery-index/src/discovery-query.ts
is not in coverage.include, so codecov/patch does not gate this path. The tests above are still
mandatory: test/unit/discovery-index/discovery-query.test.ts already exists and runs in npm run test:ci,
and the deliverables are only verifiable through it.

Both arms of every new branch must be tested: warnings-present vs warnings-empty for the repo path, the same
for the org-search path, the same for the search-terms path, and the cache-write vs cache-skip decision in
runDiscoveryQuery. The getOrCompute short-circuit (cached value present) and the compute path must both
still be exercised.

This change is NOT in packages/loopover-engine/src/**, so the dual-upload engine-coverage rule does not apply.

Fixes #10031